As part of CASSANDRA-17248 (in C* 4.0.2), the following code was introduced in QueryProcessor.java

// Make sure the missing one is going to be eventually re-prepared                
evictPrepared(hashWithKeyspace);                
evictPrepared(hashWithoutKeyspace); 

This code could very well create a race condition between two calls of QueryProcessor::prepare call in which one thread is adding and another thread is silently removing from the cache. Imagine there are thousands of threads calling the API, and then it might be possible for one thread to update the cache and another thread to remove it.

If we look at the code of Cassandra 3.0.25, then such eviction was not present. Hence, this is a regression for the post 4.0.2 version of Cassandra. To fix this issue, we should not evict the cache entries, i.e., the above-mentioned code path introduced since C* 4.0.2 is no longer required on trunk/5.0, as discussed in the ticket.

For the 4.0 branch, we will keep the eviction logic but optimize it further to address CASSANDRA-17401, as it is essential for folks on pre-4.0.1 trying to upgrade to the latest 4.0 version.

Cassandra-17401

Reproducing this is extremely tricky because it totally depends on the timing of the multiple threads, here is the pull request that reproduces it: #3058